Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.25%. Comparing base (0a75871) to head (1544d78).
⚠️ Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main    #6716      +/-   ##
==========================================
+ Coverage   83.23%   83.25%   +0.02%     
==========================================
  Files         245      246       +1     
  Lines       77361    77491     +130     
==========================================
+ Hits        64389    64519     +130     
  Misses      12972    12972              

After doing some research, I see no objection to your proposal, as I could not find any resource discouraging this type of implementation.

I think using the builtin dir in code for inspecting attributes and methods is fine, as also discussed here.
And introducing dir as a property through a mixin class is I believe a pythonic approach, knowing that such mixins were already considered for pyaedt in #5787 and implemented in #5755 for a specific functionality.

I do understand the usecase for that new property and the usability improvement. Same goes for the PyAedtBase class that could gather additional mixins or shared functionality in the future.
However, can we already think of such additions in the near future that would further populate that PyAedtBase class? In case that would not yet be very clear, I wonder if the benefits brought by DirMixin alone justify the pretty overarching refactoring performed here, given the base class gets passed to all (?) others throughout the project?

All in all, the changes do look good to me (nice that tests are provided as well)!
But given how pervasive they are and the lack of a truly relevant assessment on my part regarding the novelty introduced, I would strongly suggest waiting for @SMoraisAnsys's comments on this!

@SMoraisAnsys I understand your concerns. Regarding the utility of having dir as a property: I personally use dir() a lot for exploring properties and methods, and I know I’m not the only one. Renaming the property to something like public_attrs (or another name) it is a good compromise.

I also really like the idea of improving autocompletion by reordering the dir() output. Overriding __dir__ is a neat solution, and we can implement it easily now with the new PyAedtBase class.

@ecoussoux-ansys yes, implementing PyAedtBase was a lot of work, but now it is done 🙂 and I believe it adds real value to PyAEDT, and this kind of refactoring is best done before we reach version 1.0.

Following the suggestions from @SMoraisAnsys I renamed the dir property in public_dir.
I also defined a __dir__method to the DirMixin to sort the dir() output.

If the mixin used by the base class is imported from mixins.py, a circular import error occurs. This happens because the base class must remain independent and free of any other imports from within the same package. It should always be the rightmost class in the inheritance list of any PyAEDT class, so that the MRO places it just before the built-in object class. If PyAedtBase imports anything from pyaedt, it will cause a circular import error.

If the mixin used by the base class is imported from mixins.py, a circular import error occurs. This happens because the base class must remain independent and free of any other imports from within the same package. It should always be the rightmost class in the inheritance list of any PyAEDT class, so that the MRO places it just before the built-in object class. If PyAedtBase imports anything from pyaedt, it will cause a circular import error.

For visibility: following the comment above and a direct discussion, we agreed that the base class will be in it's own file and shouldn't have any dependency since it'll be used everywhere in the project. This will ensure that future changes do not conflict and cause circular import.